Include DNSSECProof in PaymentSent for BIP 353 proof of payment#4512
Closed
vincenzopalazzo wants to merge 2 commits intolightningdevkit:mainfrom
Closed
Include DNSSECProof in PaymentSent for BIP 353 proof of payment#4512vincenzopalazzo wants to merge 2 commits intolightningdevkit:mainfrom
vincenzopalazzo wants to merge 2 commits intolightningdevkit:mainfrom
Conversation
|
👋 Hi! I see this is a draft PR. |
BOLT12 offers are designed for compactness to fit in QR codes, and can be "much longer-lived than a particular invoice". These goals are in tension when constructing blinded paths: BOLT04 allows using either `short_channel_id` or `next_node_id` in the encrypted_data_tlv for routing, but each has trade-offs. Using SCIDs produces smaller encoded offers suitable for QR codes, but if the referenced channel closes or is modified (e.g., via splicing), the blinded path breaks and the offer becomes unusable. Using full node IDs produces larger offers but paths remain valid as long as the node connection persists, regardless of specific channel lifecycle. For long-lived offers where stability matters more than size, users may prefer full node ID paths. This adds a `compact_paths` field to `DefaultMessageRouter` and a `with_compact_paths` constructor to allow downstream applications to choose their preferred trade-off. The default behavior (compact paths enabled) is preserved.
tnull
reviewed
Mar 25, 2026
Contributor
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
I don't think we should do this. In fact, we previously discussed dropping BIP353 support from lightning entirely (in particular since it's weird HRNs might support different payment methods but here we always can only use lightning).
Rather, users should use bitcoin-payment-instructions directly as LDK Node does.
vincenzopalazzo
force-pushed
the
claude/priceless-chatelet
branch
from
b12fbee to
8596137
Compare
Store the DNSSEC proof received during BIP 353 Human Readable Name resolution and carry it through the payment lifecycle alongside the Bolt12Invoice. The proof is stored in PendingOutboundPayment::Retryable and HTLCSource::OutboundRoute (for restart persistence), and emitted in the PaymentSent event. This allows users who pay via HRN to have a complete chain of proof: DNS name -> DNSSEC proof -> Offer -> Invoice -> Payment preimage. Addresses the DNSSECProof part of lightningdevkit#3344. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
vincenzopalazzo
force-pushed
the
claude/priceless-chatelet
branch
from
8596137 to
9fd93e8
Compare
Contributor
Author
Oh I was not awere of it, I had it on my backlock from one of my older PR, nice so closing it and cleaning one item from my todo :) thanks for the review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DNSSECProofreceived during BIP 353 Human Readable Name resolution and carry it through the payment lifecyclednssec_prooffield toPendingOutboundPayment::AwaitingInvoice,Retryable,HTLCSource::OutboundRoute, andEvent::PaymentSenthandle_dnssec_proofbefore it's consumed by validation, then attach it to the payment state viaset_dnssec_proofThis gives users paying via HRN a complete chain of proof: DNS name -> DNSSEC proof -> Offer -> Invoice -> Payment preimage.
Addresses the DNSSECProof part of #3344.
Test plan
🤖 Generated with Claude Code